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INTRODUCTION 

Pursuant to the provisions of 35 U.S.C. §134 and 37 C.F.R. §§ 1.191 and 1.192, this 
paper is submitted as a brief setting forth the authorities and arguments upon which Appellant 
relies in response to the Final Rejection of Claims 1-16 in the above-identified patent application 
in the Office Action dated March 19, 2004. 
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L REAL PARTY IN INTEREST 

The real party of interest in the above-identified patent application is International 
Business Machines Corporation (IBM) of Armonk, NY. 

II. RELATED APPEALS AND INTERFERENCES 

Appellant respectfully submits that no other appeals are known to applicant, the 
applicant's legal representative, or assignee, that will directly affect or be directly affected by, or 
have a bearing on, the Board's decision in the pending appeal. 

III. STATUS OF THE CLAIMS 

Claims 1-16 are pending and appealed. Each of these claims is rejected. Claims 1, 4, 5, 7 
and 8 are independent claims. 

IV. STATUS OF THE AMENDMENTS 

Following the Final Rejection of March 19, 2004, Applicant filed amended claims in an 
after-final Response under 37 C.F.R. §1.1 16 to amend claims 1, 4, 5 and 8 to incorporate the 
subject matter of claims 10-13, respectively. An Advisory Action was mailed on July 28, 2004 
stating that the amendment has been considered but does not place the application in condition 
for allowance, and was not entered. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

The present invention relates to providing data on a network in a way that simulates that 

the data was generated from multiple clients such as workstations. The ability of a system under 

test, such as a server, to handle the data can thereby be realistically tested. The invention uses 

one or more bridge devices to provide the data in a way that is independent of any application on 

the network. In particular, the data may be provided at level 2, or the data link layer, of a 

protocol stack. The invention address a problem with prior art simulators in that they depend 

upon either the applications being run in the simulated platform and/or on the client protocol 
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stack of the simulated platform. The prior art simulators also cannot emulate realistically large 
number of clients. The invention also address problems that arise in simulating multiple clients 
from using a single physical network card, which has only one address (a medium access control 
identifier or MACID) that is assigned to the card by the manufacturer. See the specification, 
page 12, line 26 to page 13, line 32. The virtual clients cannot be realistically simulated if they 
all use the same MACID. 

In particular, claim 1 provides a simulator for inserting simulated network frames onto a 
physical medium for delivery to a system under test over a network. The simulator comprises a 
bridge device 1 104 having a network interface card for communicating with the network 1110 
(Fig. 11, page 23, line 28 to page 24, line 7). Conventionally, a bridge device can be used to join 
two or more network segments. For example, Applicant's Fig. 10 shows a conventional bridge 
1004 that joins a client local area network (LAN) 1008 and a backbone LAN 1010 (page 22, lines 
18-23). Bridging takes place in the data link layer, at level 2 of the OSI protocol stack (page 22, 
lines 23-24). The bridge device includes first and second interfaces. With Applicant's invention, 
a frame generator 1 108 is coupled to the device 1 104 via the first interface, for generating at least 
one simulated network frame from each of multiple virtual clients according to a specific 
network communications protocol. The bridge device 1 104 transfers, via the second interface, 
the at least one simulated network frame from each of the multiple virtual clients from the frame 
generator 1 108 to the system under test 1 102, such as a server, via the network to simulate traffic 
of the multiple virtual clients. For each of the multiple virtual clients, a unique identifier, such as 
a media access control identifier (MACID) (page 19, lines 6-15) combined with bridging 
information (page 24, lines 16-20) is associated with the at least one simulated network frame. 
The bridge device receives one or more network frames from the system under test via the 
network in reply to the simulated network frames transferred thereto (page 24, lines 20-29). 

As stated at page 22, lines 1-9: 

Thus, the present invention is directed to a component of a network 
simulator which virtualizes clients, i.e., enables seamless insertion of the 
simulated LAN frames onto a physical medium such as the LAN, so that they can 
then be actually delivered to a system under test just as real client LAN traffic 
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would be delivered, and enables retrieval of LAN frames from the LAN so that 
they can be delivered to the emulated clients. 

Claim 4 provides a simulator enabling insertion of simulated network frames onto a 
physical medium for delivery to a system under test implementing one or more servers to achieve 
load balancing across a network. The simulator includes a plurality of bridge devices 1204a and 
1204b (Fig. 12, page 32, lines 27-32). Each bridge device has a network interface card (page 23, 
lines 4-16). Each bridge device is connected to a respective one of the one or more servers (SI 
1202a, S2 1202b, Fig. 12, page 32, lines 29-31) employed for load balancing and enabled to 
communicate via its respective network interface card with the network. One of the plurality of 
bridge devices is designated as a primary bridge device for passing a received broadcast message, 
without delay, to the respective one of the one or more servers, via its respective network 
interface card, and another of the plurality of bridge devices is designated as a secondary bridge 
device for passing the received broadcast message, with a predetermined delay, to the respective 
one of the one or more servers, via its respective network interface card, and subsequent 
messages are sent only to the primary bridge device (page 33, line 14 to page 34, line 1). 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

(a) Whether the rejection of Claims 1, 2 and 4-16 under 35 U.S.C. § 103(a) as being 
unpatentable over U.S. patent 5,881,269 to Dobblestein in view of U.S. patent 5,996,016 to 
Thalheimer et al. (Thalheimer), and further in view of U.S. patent 5,794,128 to Brockel et al. 
(Brockel) is improper. 

(b) Whether the rejection of Claim 3 under 35 U.S.C. § 103(a) as being unpatentable over 
U.S. patent 5,881,269 to Dobblestein in view of U.S. patent 5,996,016 to Thalheimer et al. 
(Thalheimer), further in view of U.S. patent 5,794,128 to Brockel et al. (Brockel), and further in 
view of U.S. patent 6,530,078 to Shmid et al. (Shmid) is improper. 
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VII. ARGUMENT 

(a) The rejection of Claims 1, 2 and 4-16 under 35 ILS.C. 
§103(a) as being unpatentable over U.S. patent 5,881,269 to 
Dobblestein in view of U.S. patent 5,996,016 to Thalheimer et 
al. (Thalheimer), and further in view of U.S. patent 5,794,128 
to Brockel et al. (Brocket) is improper. 

Claim 1 

Dobblestein uses a single workstation to simulate multiple LAN clients. A client 
machine 80 and a server machine 8 1 are coupled by a network 83 (col. 4, lines 22-24). A 
redirector 48 serves as an interface between the client applications 47 and the network 83 (col. 5, 
lines 4 and 5). Requests from the client applications 47 are converted by the redirector 48 to 
SMB packets and sent via the transport layers 49, 50 to the server 81 via a network adapter 40. 
The transport layer 49 is a NetBEUI protocol driver, while the transport layer 50 is a MAC driver 
(col. 5, lines 61-65). The client request or message is converted into SMB packets (col. 5, lines 
33-35). At the server 81, the message is received via a network adapter 131. A MAC driver 133 
sends the message from the client up the protocol stack 135 (NetBEUI) to a redirector 139 of the 
server (col. 6, lines 23-41). The harvester mechanism 51 obtains copies of the SMB traffic from 
the redirector to simulate multiple clients at the single workstation (col. 6, lines 42-45). 

The Dobblestein approach is therefore rather different than the invention of claim 1 
Claim 1 sets forth a simulator that includes a bridge device and a frame generator. The frame 
generator is coupled to a first interface of the bridge device. The frame generator generates at 
least one simulated network frame from each of multiple virtual clients. This is in contrast to the 
Dobblestein approach, wher e the same data from a client is merely copied to simulate multiple 
clients . Moreover, claim 1 sets forth that for each of the multiple virtual clients, a unique 
identifier combined with bridging information is associated with the at least one simulated 
network frame. Again, Dobblestein fails to disclose or suggest this feature. Regarding the 
multiple threads 55', 55" and 55'" in Fig. 3 of Dobblestein, these are threads that act like 
separate LAN clients. However, these are not identifiers associated with simulated network 
frames that are transferred to a system under test, as claimed. Moreover, Dobblestein does not 
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disclose or suggest the use of a bridge as claimed by Applicant. Instead, the client simulation of 
Dobblestein is performed entirely at a workstation, and not at any bridge. 

Thalheimer is cited by the Examiner as providing the missing element of a bridge. 
Thalheimer provides multiple IP applications in a single processing system by intercepting a bind 
call from an application and binding the application to an alternate IP address, which is an 
address other than the default IP address associated with the network interface (col. 4, lines 24- 
44). In a simulated network (Figure 4), a master station 51 in a network 50 maintains a list of 
network and aliased addresses. A processing system 20 is connected to the network 50 and 
provides a simulated router function 52, which provides the aliased IP addresses, and simulated 
subnets 54, 56 and 58. 

Applicant respectfully disagrees with the Examiner's assertion that Thalheimer discloses 
routing simulated network frames using bridging information. As indicated, Thalheimer is only 
concerned with a simulated router function 52 (col. 5, line 42) and not a bridge device as 
claimed. A bridge operates at the data link layer of a protocol stack. For example, this may be 
level 2 of the Open System Interconnection (OSI) protocol. In contrast, a router operates at the 
network layer such as level 3 of the OSI protocol, and is therefore protocol dependent . 

Advantageously, Applicant's simulator can remain protocol neutral. Any necessary 
protocol specific routing functions can be subsumed by the simulator and not exposed to the 
system being tested. The purpose is to simulate and virtualize clients attached to any arbitrary 
network. The invention is contrary to Dobblestein, where the protocol stack is unmodified, as is 
the network attachment device at the bottom of the stack. Thus, contrary to the invention, the 
network frames from the network adapter 131 of Dobblestein will have the same data link layer 
identifier, such as MACID. Similarly, the invention is in contrast to Thalheimer, where the 
protocol stack is unmodified (except for the provision of an exit point) as is the network 
attachment device at the bottom of the protocol stack. 

Accordingly, Thalheimer does not disclose or suggest the missing element of a bridge 
device as claimed by Applicant. 



6 



G:\Ibm\ 1 345\1 2866\AM END\i 2866 appeal brief.BR 1 .doc 



The Examiner relies on Brockel as teaching the missing element of simulation of bridging 
protocols at the data link layer, and a plurality of virtual clients (Office Action, page 6, lines 1-3). 
However, Brockel cannot cure the deficiencies of Dobblestein and Thalheimer. 

Brockel discloses a system for simulating a military war game scenario by simulating 
wireless information transport systems that replicate time and frequency dynamics effects on 
stationary and mobile communications systems (Abstract). To this end, Brockel provides a 
network simulation means 9 (Fig. 4) that is responsive to simulation inputs 13 (column 7, lines 2- 
6). The network simulation means 9 simulates a plurality of simultaneous voice, data and 
imagery information exchanges at intranetwork and internetwork levels among stationary and 
moving platforms (column 7, lines 36-40). Additionally, in operation of the network simulation 
means 9, simulation of a plurality of protocols at each layer may be selected by the operator, 
including a plurality of Internet protocol services and a plurality of networking capabilities such 
as routing, relaying, address-resolution and interworking (column 8, lines 1-6). 

Accordingly, Brockel is concerned with a simulated network, not a real network . In 
particular, Brockel seeks to simulate the behavior of a real network and communication 
environment by simulating, e.g., variations in connection quality and other communications and 
connectivity problems on the digitized battlefield caused by radio communications (column 7, 
lines 43-49). 

The Examiner asserts that Brockel discloses the simulation of bridging protocols at the 
data link layer. Applicant respectfully disagrees with this assertion. Regarding Figures 2-5 cited 
by the Examiner to support the assertion, there is no mention of bridging. Regarding column 5, 
lines 16-36, this passage refers to simulating a wireless information transport system, but there is 
no mention of bridging. Regarding column 8, lines 8-12 state: "A data link layer of said network 
simulation means 9 provides capabilities relating to functions such as data-flow control, roving 
host configuration protocol and error-correction and recovery." Again, there is no mention of 
bridging. 

In fact, a bridge is only mentioned once by Brockel, at column 6, lines 23-31, in defining 

a node. It is noted that a node refers to a single communications center from which information 
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either originates, terminates or is passed through, and can include a single radio, cellular phone, 
repeater, switch or computer terminal and any combination of gateways or routes, bridges and 
computer terminals. 

Furthermore, note that Applicant's claim 1 sets forth a "bridge device," e.g., a physical 
device, with interfaces for communicating with other real entities, such as a frame generator, a 
network and a system under test. In contrast, as mentioned, Brockel is only concerned with a 
simulated network with simulated components, and not with a real component such as a bridge 
device as claimed. This is an important distinction over the cited references since Applicant's 
invention provides the ability to test a real system under test, such as a server, by providing 
realistic client/server network traffic and load (specification, page 13, lines 5-8). 

Accordingly, it can be seen that Brockel does not teach the missing element of simulation 
of bridging protocols at the data link layer, as claimed by Applicant. 

The Examiner further asserts that it would be obvious to combine the teachings of 
Dobblestein, Thalheimer and Brockel, and that such a combination renders Applicant's claims 
obvious. The Examiner asserts that such a combination is motivated by the desire to solve the 
problems of developing a wireless network by using a simulator as opposed to using real 
hardware and field tests. However, Applicant's invention in fact uses real hardware, e.g., a 
bridge device, which tests the capacity of a real system under test, such as a server in a network. 
Accordingly, a person of skill in the art would not consider the teachings of Brockel, which is 
directly solely to testing a simulated network, not a real network in the manner suggested. 
Moreover, the asserted motivation for the combination is not provided by the references 
themselves, expressly or impliedly, or by a convincing line of reasoning based on scientific 
principles, but could only be provided impermissibly in hindsight. 

Furthermore, as mentioned, the combination of Dobblestein, Thalheimer and Brockel still 
does not lead one of ordinary skill in the art to the present invention at least since Brockel does 
not teach a bridge device operating at a data link layer in a protocol stack, for the reasons 
mentioned above. 
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Moreover, it is not clear how the teachings of Brockel could be combined with the 
teachings of Dobblestein and Thalheimer into a working system since Dobblestein uses client 
and server machines 80, 81, respectively, connected by a real LAN 83, not a simulated network, 
but Thalheimer is not concerned with simulating the behavior of a real network and 
communication environment. 

The rejection is therefore improper. 

Claim 4 

Regarding claim 4, this claims relates to a simulator having a plurality of bridge devices, 
for load balancing. A primary bridge device passes a received broadcast message, without delay, 
to a server, while a secondary bridge device passes the received broadcast message, with a 
predetermined delay, to the server. Subsequent messages are sent only to the primary bridge 
device. The Examiner cites item 52 (Fig. 4) in Thalheimer as showing a plurality of bridges. 
However, item 52 is a simulated router function (col. 5, line 42), not a bridge device as claimed 
by Applicant. Moreover, Thalheimer provides no disclosure or suggestion the simulated router 
function 52 comprising primary and secondary bridge devices as set forth in claim 4, where the 
primary bridge device passes a received broadcast message without delay, and the secondary 
bridge device passes the received broadcast message with a predetermined delay. Dobblestein 
similarly provides no disclosure or suggestion of the simulator of claim 4. Accordingly, the 
combination of these two references simply could not lead one of ordinary skill in the art to the 
invention of claim 4. 

Furthermore, Applicant respectfully submits that the Examiner has not pointed out where 
each of the features of independent claim 4 are shown by the prior art. Accordingly, a prima 
facia case of obviousness has not been made (MPEP 2142). 

Regarding the Examiner's assertion that it would be obvious to combine Dobblestein 

with Thalheimer since adding a bridge/router functionality to a simulation of a network would 

cause the simulation of the network to more closely approximate the way a real network operates, 

Applicant notes that Dobblestein is not concerned with causing the simulation of a network to 

more closely approximate the way a real network operates. Instead, Dobblestein is concerned 
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with simulating multiple network clients on a single workstation . To this end, Dobblestein uses a 
client machine 80 and a server machine 81 that are coupled by a real LAN 83. There is no 
concern whatsoever with simulating a LAN or other network. Accordingly, the asserted 
motivation for combining Dobblestein and Thalheimer is not valid. 

Applicant comments regarding Brockel and the other references relative to claim 1 are 
incorporated herein. 

The rejection is therefore improper. 

Claims 10 and 11 

These claims set forth that the bridge devices of independent claims 1 or 4, respectively, 
operate at a data link layer in a protocol stack. As mentioned in Section V, above, the invention 
uses one or more bridge devices to provide data for testing a system under test, such as a server, 
in a way that is independent of any application on the network. This is achieved by providing the 
data at level 2, or the data link layer, of a protocol stack. For example, Fig. 2 of the specification 
shows the prior art Open Systems Interconnection (OSI) protocol stack model, with the data link 
layer 204. See the specification, page 12, line 27 to page 13, line 3. 

The Examiner asserts that Brockel discloses the simulation of bridging protocols at the 
data link layer. Applicant respectfully disagrees with this assertion. As stated above in 
connection with claim 1, regarding Figures 2-5 of Brockel cited by the Examiner to support the 
assertion, there is no mention of bridging. Regarding column 5, lines 16-36, this passage refers 
to simulating a wireless information transport system, but there is no mention of bridging. 
Regarding the cited column 8, lines 1-20, note that lines 8-12 in particular state: "A data link 
layer of said network simulation means 9 provides capabilities relating to functions such as data- 
flow control, roving host configuration protocol and error-correction and recovery." Again, there 
is no mention of bridging. 

In fact, a bridge is only mentioned once by Brockel, at column 6, lines 23-3 1 , in defining 
a node. It is noted that a node refers to a single communications center from which information 
either originates, terminates or is passed through, and can include a single radio, cellular phone, 
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repeater, switch or computer terminal and any combination of gateways or routes, bridges and 
computer terminals. 

Furthermore, note that Applicant's claim 1 sets forth a "bridge device," e.g., a physical 
device, with interfaces for communicating with other real entities, such as a frame generator, a 
network and a system under test. This is an important distinction over the cited references since 
Applicant's invention provides the ability to test a real system under test, such as a server, by 
providing realistic client/server network traffic and load (specification, page 13, lines 5-8). 

The rejection is therefore improper. 

(b) The rejection of Claim 3 under 35 U.S.C. §103(a) as being 
unpatentable over U.S. patent 5,881,269 to Dobblestein in 
view of U.S. patent 5,996,016 to Thalheimer et al. 
(Thalheimer), further in view of U.S. patent 5,794,128 to 
Brocket et al. (Brockel), and further in view of U.S. patent 
6,530,078 to Shmid et al. (Shmid) is improper. 

Claim 3 

Claim 3 sets forth that the frame generator of independent claim 1 is coupled to the bridge 
device via an Open System Adapter connection. 

Shmid is cited as providing the missing element of an Open System Adaptor connection. 
Shmid discusses the use of an Open System Adaptor for giving a DPPX guest system access to 
TCP/IP networks (column 9, lines 31-35). However, Applicant respectfully submits that this 
teaching, even in combination with the other references, does not lead one of ordinary skill in the 
art to Applicant's invention, where a frame generator is coupled to a bridge device using an Open 
System Adapter connection. In particular, Shmid discloses a method to quickly migrate 
applications from any operating system to an OS/390 operating system. Thus, Shmid only 
supplies an operating platform that is available natively. The virilization provided by Shmid is 
unneeded and only adds to the cost of a solution provided by a simulator alone. Thus, there is no 
motivation to combine Shmid with any simulator . Generally, to establish prima facie 
obviousness, there must be some suggestion or motivation to modify a reference. See, In re 
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Rouffet, 149 F.3d 1350, 1355, 47 USPQ2d 1453, 1457 (Fed. Cir. 1998). "Rarely, however, 
will the skill in the art component operate to supply missing knowledge or prior art to reach an 
obviousness judgment." Al-SiteCorp. v. VSI International Inc., 174F.3d 1308, 50 USPQ2d 
1161 (Fed. Cir. 1999). 

The rejection is therefore improper. 

CONCLUSION 

In view of the above, the references applied against Claims 1-16 do not render those 
claims obvious under 35 U.S.C. § 103(a). Accordingly, Applicant respectfully submits that the 
rejections are in error and must be reversed. 

The Commissioner is hereby authorized to charge any additional fees or credit any 
overpayment in connection herewith to Deposit Account No. 19-1013/SSMP. 

Respectfully submitted, 

Ralph F. Hoppin 
Reg. No. 38,494 

SCULLY SCOTT MURPHY & PRESSER 
400 Garden City Plaza, Suite 300 
Garden City, New York 11530 
(516) 742-4343 

SF/RH/kc 
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VIIL CLAIMS APPENDIX 



CLAIMS ON APPEAL: CLAIMS 1-16 

Application Serial No. 09/517,465 

1 . A simulator for inserting simulated network frames onto a physical medium for 
delivery to a system under test over a network, comprising: 

a bridge device having a network interface card for communicating with the network; 
the bridge device including first and second interfaces; and 

a frame generator, coupled to the device via the first interface, for generating at least one 
simulated network frame from each of multiple virtual clients according to a specific network 
communications protocol; wherein: 

the bridge device transfers, via the second interface, the at least one simulated network 
frame from each of the multiple virtual clients from the frame generator to the system under test 
via the network to simulate traffic of the multiple virtual clients; 

for each of the multiple virtual clients, a unique identifier combined with bridging 
information is associated with the at least one simulated network frame; and 

the bridge device receives one or more network frames from the system under test via the 
network in reply to the simulated network frames transferred thereto. 

2. The simulator of claim 1 , wherein the frame generator is coupled to the bridge 
device via a channel connection. 

3. The simulator of claim 1 , wherein the frame generator is coupled to the bridge 
device via an Open System Adapter connection. 
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4. A simulator enabling insertion of simulated network frames onto a physical 
medium for delivery to a system under test implementing one or more servers to achieve load 
balancing across a network, comprising: 

a plurality of bridge devices, each having a network interface card, and each connected to 
a respective one of the one or more servers employed for load balancing and enabled to 
communicate via its respective network interface card with the network; wherein: 

one of the plurality of bridge devices is designated as a primary bridge device for passing 
a received broadcast message, without delay, to the respective one of the one or more servers, via 
its respective network interface card, and another of the plurality of bridge devices is designated 
as a secondary bridge device for passing the received broadcast message, with a predetermined 
delay, to the respective one of the one or more servers, via its respective network interface card; 
and subsequent messages are sent only to the primary bridge device. 

5. A method for inserting simulated network frames onto a physical medium for 
delivery to a system under test, comprising: 

connecting a bridge device with a network interface card having a unique identifier to a 
network; 

receiving simulated network frames from a frame generator coupled to the bridge device; 

configuring bridging information in the bridge device to include identifiers associated 
with the simulated network frames, the identifiers emulating identifiers of a plurality of client 
workstations; and 

forwarding the simulated network frames onto the network via the network interface card. 

6. The method of claim 5, further comprising: 

receiving network frames representing replies from a server designated for the plurality of 
client workstations based on the configured bridging information, wherein the received network 
frames have unique frame identifiers representing the plurality of client workstations. 
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7. A method for inserting simulated network frames onto a physical medium for 
delivery to a system under test implementing one or more servers to achieve load balancing, 
comprising: 

connecting a bridge device for each server in a load balancing system having a plurality 
of servers; 

a primary of the bridge devices transmitting a client request immediately to a first server 
connected to the primary bridge device; 

a secondary of the bridge devices transmitting the client request after a predetermined 
amount of time to a second server connected to the secondary bridge device; and 

transmitting subsequent client requests to the primary bridge device . 

8. A program storage device readable by machine, tangibly embodying a program of 
instructions executable by the machine to perform a method for inserting network frames onto a 
physical medium for delivery to a system under test, the method comprising: 

connecting a bridge device with a network interface card having a unique identifier to a 
network; 

receiving simulated network frames from a frame generator coupled to the bridge device; 

configuring bridging information in the bridge device to include identifiers associated 
with the simulated network frames, the identifiers emulating identifiers of a plurality of client 
workstations; and 

forwarding the received simulated network frames onto the network via the network 
interface card. 

9. The program storage device of claim 8, wherein the method further includes: 
receiving network frames representing replies from a server designated for the plurality of 

client workstations based on the configured bridging information, wherein the received network 
frames have unique frame identifiers representing the plurality of client workstations. 
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10. The simulator of claim 1, wherein: 

the bridge device operates at a data link layer in a protocol stack. 

1 1 . The simulator of claim 4, wherein; 

the bridge devices operate at a data link layer in a protocol stack. 

12. The method of claim 5, wherein: 

the bridge device operates at a data link layer in a protocol stack. 

13. The program storage device of claim 8, wherein: 

the bridge device operates at a data link layer in a protocol stack. 

14. The simulator of claim 1 , wherein: 

for each of the multiple virtual clients, the unique identifier comprises a data link layer 
identifier. 

15. The method of claim 5, wherein: 

the identifiers associated with the simulated network frames comprises data link layer 
identifiers. 

16. The program storage device of claim 8, wherein: 

the identifiers associated with the simulated network frames comprises data link layer 
identifiers. 
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